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The retransmission of signaling 
that data terminals (e.g., modems) might 
exchange prior to exchanging user data is con- 
trolled by arranging a data terminal that re- 
ceives multiple copies of the same signaling 
message so that it saves only the first copy 
thereof, but transmits a response to the sending 
terminal following receipt of each such copy. 
The sending terminal terminates its transmis- 
sion of the signaling message upon receipt of a 
response from the receiving terminal. The in- 
ventive procedure Is especially advantageous 
for controlling the retransmission of signaling 
messages during a n-way handshake between 
two terminals. 
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Field of the Invention 

The invention generally relates to communica- 
tions systems and more particularly relates to a trans- 
mission protocol for data terminals. 

Background of the Invention 

A data link control protocol, such as the well- 
known HDLC protocol, has been the basis for a large 
class of signaling protocols including, for example, 
the X.25 Layer 2, Q.921 and GSM 04.22 protocols 
covering wired and wireless applications. These pro- 
tocols typically follow the same procedure that a data 
terminal invokes to (a) establish a connection or dis- 
connection, (b) negotiate transmission parameters, 
or (c) exchange operating status information. The 
procedure typically entails transmitting a signaling 
message and setting a timer (which is typically set to 
approximately several times the round-trip transmis- 
sion delay between the near and far-end) to await re- 
ceipt of a far-end response to the message. If the 
transmitted signaling message or transmitted re- 
sponse is lost due to, for example, a noisy connection, 
then the near-end terminal will not learn of that fact 
until the associated timer expires. At that point, the 
near-end terminal may retransmit the lost signaling 
message and reset the associated timer. The near- 
end terminal repeats the foregoing procedure if the 
transmitted message continues to be lost as a result 
of the noisy connection and does so until it declares 
an unrecoverable error condition. 

It can be appreciated that the foregoing proce- 
dure consumes an inordinate amount of time and is 
not very efficient. This would be true even if the 
transmitted message reaches the far end after a num- 
ber of transmission attempts and an acknowledge- 
ment response is received at the near end. It is obvi- 
ous of course that the foregoing may be dealt with to 
some extent by decreasing the timing period of the 
associated timer as a way of decreasing the duration 
between retransmissions and thus the overall delay. 
However, we have recognized that in the absence of 
a well-defined set of transmission procedures such a 
decrease in the value of the timer could place either 
or both the near-end or far-end terminal (which may 
be receiving repeatedly a copy of same signaling 
message) in an ambiguous state. 

Summary of the invention 

The invention in accordance with claim 1. 
Brief Description of the Drawing 
In the drawing: 

FIG. 1 is a broad block diagram of a data commu- 
nications system in which the principles of the in- 



vention may be practiced; 
FIGs. 2 and 3 are timing diagrams respectively il- 
lustrating the way in which the principles of the in- 
vention may be used in a three-way and two-way 
5 handshake procedure; and 

FIGs. 4 through 9 illustrate in flow chart form the 
programs which implement the principles of the 
invention in the system of FIG. 1. 

10 Detaiied Description 

In an exemplary embodiment of the invention, a 
transceiver section 1 00, FIG. 1 , of a data terminal op- 
erates in accord with a predetermined transmission 

15 protocol. Such a protocol may specify a so-called up- 
per layer controller 1 0 for controlling the processing 
of a call and associated call connection represented 
by link 150. Link 150, more particularly, may be a call 
connection that is established between data terminal 

20 1 00 and data terminal 200 and may include, in part, 
a radio link. (It is noted that the operation of transceiv- 
er 200 is similar to that of transceiver 1 00. Thus, any 
discussion pertaining to transceiver 100 equally per- 
tains to transceiver 200, and vice versa.) Call Con- 

25 nection Controller (CCC) 10 establishes a call con- 
nection by communicating with Signaling Protocol 
Controller (SPC) 20. CCC 10 also controls the con- 
nection during the call in the same way. That is, CCC 
supplies signaling messages to that effect to SPC 20, 

30 which then stores the messages in signaling-mes- 
sage-transmit buffer 30. SPC 20 then unloads the 
messages one at a time and in the order that they 
were stored in buffer 30 and transmits each unloaded 
message over connection 150 via a conventional ra- 

35 dio-link modem 40, all in accord with the inventive 
protocol. 

Since connection 150 may contain a radio link 
that may be subject to a high error rate (or high loss 
of data packets), then it is likely that a signaling mes- 

40 sage that is transmitted over connection 1 50 may not 
reach data terminal 200. We deal with that problem, 
in accord with an aspect of the Invention, by repeat- 
edly transmitting a signaling message until either the 
recipient responds to receipt of the message or a 

45 transmission timer expires. 

Specifically, when SPC 20 passes a signaling 
message to modem 40 for transmission over connec- 
tion 150, SPC 20 then activates an abort timer 5 to set 
the duration of time over which the signaling message 

so is repeatedly transmitted or until an acknowledge- 
ment thereof is received from terminal 200. In an Il- 
lustrative embodiment of the invention, SPC 20 asso- 
ciates each message that is transmitted with an abort 
timer 5, which is implemented in memory internal to 

55 SPC 20 and which may have a duration of, for exam- 
ple, ten second. If an acknowledgement is received 
within that period of time, then SPC 20 notifies CCC 
10 thereof and cancels timer 5. In accord with an as- 
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pect of the invention, the duration between repeated 
transmissions of the signaling message may be con- 
trolled by repeat timer 1 5, which is activated following 
the transmission of a signaling message and which 
may be set for a duration of, for example, one hundred 5 
milliseconds. SPC 20 then retransmits the message 
at the expiration of timer 15 if (a) timer 5 has not ex- 
pired and (b) an acknowledgement has not yet been 
received from terminal 200. 

A signaling message may be, for example, part of 10 
a conventional two-way, three-way or n-way hand- 
shake procedure. A three-way handshake procedure 
is usually invoked during the establishment of a con- 
nection and involves the negotiation of operating 
parameters that control the exchange of user infor- 15 
mation. (A three-way handshake procedure may also 
be invoked whenever one or more of the parameters 
is changed.) A two-way handshake, on the other 
hand, is typically invoked after a connection has been 
established to inform the terminal at the other end of 20 
the connection of a change in an operating state, for 
example, when a terminal is not ready or when a ter- 
minal refuses to execute a particular request 

Turning now to FIG. 2, there is shown an example 
of the way in which the inventive protocol controls the 25 
exchange of messages defining a three-way hand 
shake between data terminals communicating with 
one another over a noisy link, e.g., a wireless link. The 
handshake is initiated when terminal 100 transmits 
signaling message s1. For example, assume that 30 
message s1 proposes a particular transmission win- 
dow size for controlling the exchange of messages 
between terminals 100 and 200. With that in mind, as- 
sume at this point that, as a result of link 150 being 
noisy, message s 1 is lost and does not reach terminal 35 
200. However, In accord with the inventive protocol, 
terminal 100 automatically repeats the transmission 
of message s1 for some period of time after the trans- 
mission of message s1 and, as mentioned above, will 
continue to do so until it either receives a response 40 
from terminal 200 or the timer 5 associated with mes- 
sage s1 expires. The retransmission starts with mes- 
sage s2 and is repeated thereafter, as represented by 
messages s3 through s7, which are transmitted every 
100 milliseconds, for example, eachtime repeattimer 45 
15 expires as shown in FIG. 2 by a2. The illustrative 
example assumes that terminal 200 receives repeat- 
ed message s2 and passes message s2 to its asso- 
ciated CCC 10. The terminal 200 CCC 10, in turn, 
generates a response and supplies the response to so 
its associated SPC 20 for transmission to terminal 
100 as represented in the FIG. by message rl. As- 
sume that response message r1 is also lost as a result 
of the noisy link. Similarly, terminal 200, in accord 
with the inventive protocol, automatically repeats the 55 
transmission of message r1 until either it receives an 
acknowledgement from terminal 100 or the timer 5 
associated with message r1 expires. The repeated 



transmission of message r1 is represented in the FIG. 
by messages r2 through r6 which are transmitted at 
a rate determined by duration a2, e.g., every 40 mil- 
liseconds. 

Assume at this point that signaling messages s3, 
s5 and s6 are also lost due to the noisy wireless link 
and that terminal 200 receives messages s4 and s7. 
Upon receipt of message s4, terminal 200 notes that 
message s4 is a copy of priorly received message s2, 
and therefore discards message s4. Terminal 200 
processes message s7 similarly. 

It is seen from the FIG. that terminal 100 receives 
response message r2 following the transmission of 
repeat message s7. The terminal 1 00 SPC 20, in turn, 
passes the message to the terminal 1 00 CCC 1 0, and 
stores the message in signaling message buffer 30. 
In addition, SPC 20 then compares the message r2 
with priorly transmitted message s1. In doing so, SPC 
20 determines that message r2 is a response to mes- 
sage s1, and, therefore, erases message s1 from buf- 
fer 30, thereby terminating the retransmission of that 
message. In addition, SPC 20 clears the timers 5 and 
15 associated with message s1. SPC 20 then trans- 
mits message ack(r2) acknowledging receipt of mes- 
sage r2. 

In accord with an aspect of the invention, the in- 
ventive protocol treats an acknowledgement mes- 
sage, e.g., message ack(r2) different from the way it 
treats a signaling message, e.g., message s1. Spe- 
cifically, the transmission of an acknowledgement 
message is not automatically repeated. Thus, a timer 
1 5 is not associated with a transmitted acknowledge- 
ment message. What this means is that an acknowl- 
edgement message is transmitted once for each re- 
sponse message and for each copy of such a mes- 
sage that a terminal, e.g., terminal 1 00, receives. This 
is shown in the FIG. for message ack(r2) which is lost 
and not received by terminal 200. Also consider re- 
sponse messages r3 and r6, which terminal 1 00 (SPC 
20) receives and therefore transmits message 
ack(r3) acknowledging receipt of message r3 and 
message ack(r6) acknowledging receipt of message 
r6. 

Terminal 200 (SPC 20 thereof), on the other 
hand, terminates its repeated transmission of the re- 
sponse message (illustrated as rl, r2....r7 in FIG. 2) 
as a result of receiving message ack(r3) after having 
transmitted message r6. In response to receipt of 
ack(r3), SPC 20 of terminal 200 (a) passes the ack(r3) 
message to CCC 10 of terminal 200, (b) clears all 
timers associated with message r1 and (c) erases 
message r1 from buffer 30 of terminal 200. There- 
after, SPC 20 of terminal 200 responds to receipt of 
message ack(r6) by discarding the message since 
there is no corresponding response message stored 
in buffer 30 of terminal 200. 

As mentioned above, a two-way handshake is 
used to inform another terminal of a change in an op- 
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erating state, for example, receiver not ready (which 
might possibly occur as a result of a buffer overflow, 
rejection of a request message, or request for a status 
update and the response thereto). Accordingly, a two- 
way handshake does not involve a negotiated ex- 5 
change of parameters. In that case then, a two-way 
handshake only requires the receiving station to ac- 
knowledge receipt of a command message specify- 
ing a change in an operating state of the transmitting 
terminal. What this means is that the receiving station 10 
does not have to transmit a response message as 
would be the case for a three-way handshake. 

FIG. 3 is an illustrative example of the way in 
which the inventive protocol controls the transmis- 
sion of a response to the receipt of a two-way hand- 1 s 
shake message, d. It is seen from the FIG. that ter- 
minal 100 repeatedly retransmits message c1 until it 
receives acknowledgement message ack(c3). Simi- 
larly, terminal 200 transmits an acknowledgement 
message responsive to receipt of the command mes- 20 
sage d and each copy thereof, namely messages c3, 
c4, c5 and c7. 

On receipt of message c3, SPC 20 of terminal 200 
stores the message in its associated buffer 30 and 
passes a copy of the message to CCC 1 0 of terminal 25 
200. When messages c4 and c7 are received subse- 
quently in sequence, SPC 20 discards each of those 
messages as a result of finding that they are a copy 
of the c3 message that is already stored in buffer 30. 
It is seen from the FIG. that as a result of receiving the 30 
latter command messages, terminal 200 transmits 
acknowledgement messages ack(c3), ack(c4), 
ack(c5) and ack(c7), respectively. 

It is noted that upon receipt of message ack(c3), 
SPC 20 of terminal 100 similarly notifies CCC 10 35 
thereof and then determines if message ack(s2) is a 
response to message c1. If so, then SPC 20 erases 
message d from buffer 30, thereby terminating the 
retransmission of that message. In addition, SPC 20 
clears the timers 5 and 15 associated with message 40 
d. 

FIG. 4 illustrates the SPC 20 program that is en- 
tered responsive to receiving a signaling message 
from its associated CCC 10 for transmission over the 
established connection 150. For example, when the 45 
CCC of transceiver (terminal) 100 initiates a three- 
way (two-way) handshake it executes the program il- 
lustrated in FIG. 4 to transmit a request (or command 
in the case of a two-way handshake) message to 
transceiver 200. The program illustrated in FIG. 5 is so 
entered to provide repeated transmission of a signal- 
ing message until a response (or ack in the case of a 
two-way handshake) is received from the other end 
of the connection. On receipt of the request (com- 
mand in the case of a two-way handshake) message, 55 
terminal 200 executes the program illustrated in FIG. 
6 (FIG. 8 for a two-way handshake) to process the re- 
ceived message. The CCC of terminal 200 then gen- 



erates a response message which is transmitted to 
terminal 100 using the program illustrated in FIGs. 4 
and 5. When the response arrives at terminal 100, 
then the program illustrated in FIG. 7 is executed to 
receive and process the response message. The pro- 
gram illustrated in FIG. 9 is executed at terminal 200 
(100 in the case of a two-way handshake) to conclude 
the handshake procedure between terminals 1 00 and 
200. Specifically at block 401, the program transmits 
the message and then stores the message in the as- 
sociated transmit buffer 30. The program then pro- 
ceeds to blocks 402 and 403 where it associates 
timers 5 and 15 with the message and then. activates 
those timers. The program then exits at block 404. 

FIG. 5 illustrates the program which manages 
each activated timer 15. Specifically, the program is 
entered at block 500 periodically ( e.g., every 1 00 mil- 
liseconds when timer 15 expires) and proceeds to 
block 501 where it checks to see if the associated 
timer 5 has expired. If so, then the program (block 
502) declares an unrecoverable error state, cancels 
timers 5 and 15 and then exits. If not, then the pro- 
gram (block 503) transmits the associated message. 
The program (block 504) then resets timer 15 and 
then exits. 

The program of FIG. 6 is entered upon receipt of 
a request message via the associated modem and es- 
tablished connection and immediately proceeds to 
block 601 where it checks to see if a copy of the mes- 
sage has already been stored in its associated re- 
ceive buffer 40. If so, then the program (block 602) 
discards the message and then exits. If not, then the 
program (block 603) stores the message in its asso- 
ciated receive buffer 40 and passes a copy of the 
message to its associated CCC 10. The program then 
exits. 

The program of FIG. 7 is entered at block 700 
upon receipt of a response message transmitted by 
the far-end terminal in response to an earlier request 
message. When entered, the program proceeds to 
block 701 where it checks to see if a copy of the mes- 
sage has already been stored in its associated re- 
ceive buffer 40. If so, the program (block 702) trans- 
mits an acknowledgement message (ack) and then 
discards the received message. The program then 
exits. If not, the program (block 703) checks to see if 
the corresponding request message was stored pre- 
viously in transmit buffer 30. If not, then the program 
(block 704) discards the received message and then 
exits. If so, the program (block 705) (a) stores the re- 
ceived message in Its associated receive buffer 40, 
(b) passes a copy of the message to its associated 
CCC 10 and (c) transmits an ack message acknowl- 
edging receipt of the response message. The pro- 
gram (block 706) then erases the corresponding re- 
quest message from its transmit buffer 30 and clears 
the associated timers 5 and 15. The program then ex- 
its. 
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The program of FIG. 8 is entered upon receipt of 
a command message and proceeds to block 801 
where it checks to see if a copy of the command mes- 
sage has already been stored in its associated re- 
ceive buffer 40. If so, then the program (block 802) 5 
transmits an acknowledgement message (ack) and 
then discards the received message. The program 
then exits. If not, then the program (block 803) (a) 
stores the received message in its associated receive 
buffer 40, (b) passes a copy of the message to its as- 1 o 
sociated CCC 10 and (c) then transmits an ack mes- 
sage acknowledging receipt of the command mes- 
sage. The program then exits. 

The program of FIG. 9 is entered upon receipt of 
an acknowledgement (ack) message to an earlier re- 15 
sponse or command message. When so entered, the 
program proceeds to block 901 where it checks to see 
if a copy of the ack message has already been stored 
in its associated receive buffer 40. If so, then the pro- 
gram (block 902) discards the received ack message. 20 
The program then exits. If not, the program (block 
903) checks to see if the corresponding response or 
command message was stored previously in transmit 
buffer 30. If not, then the program (block 904) dis- 
cards the received ack message and then exits. If so, 25 
the program (block 905) (a) stores the received mes- 
sage in its associated receive buffer 40, and (b) pass- 
es a copy of the ack message to its associated CCC 
10. 

The foregoing is merely illustrative of the princi- 30 
pies of the invention. Those skilled in the art will be 
able to devise numerous arrangements, which, al- 
though not explicitly shown or described herein, nev- 
ertheless embody those principles that are within the 
spirit and scope of the invention. For example, since 35 
a signaling procedure may be initiated at either the 
near- or far-end transceiver (e.g., terminal 100 or 
200), then there is a chance that multiple independent 
procedures may be active simultaneously. Also, dif- 
ferent method sequences should be uniquely identi- 40 
f led so that a response may be associated with a par- 
ticular request. 

Further, if two transceivers Initiate signaling pro- 
cedures of different levels of priority, then the proce- 
dure having the higher level of priority may cause the 45 
lower priority procedure to abort. This case might oc- 
cur when, for example, a CCC responds to a request 
by transmitting a high priority request, rather than a 
response to the received request. 

Still further, If two transceivers simultaneously so 
initiate procedures of equal priority, then a contention 
resolution scheme may be invoked to deal therewith. 
Such a contention resolution scheme may include the 
claimed invention. For example, if the two terminals 
determine between themselves which has the higher 55 
priority by using their respective serial numbers or 
some other attribute, then the lower priority terminal 
may abort its procedure. As another example, if a 



transceiver (terminal) receives from another trans- 
ceiver a request having a priority equal to that of a re- 
quest that it just transmitted, then the receiving trans- 
ceiver enters a state indicative of receiving a valid re- 
sponse to its transmitted request. 



Claims 

1. Apparatus to control the exchange of signaling 
messages between first and second data termi- 
nals, individual ones of the signaling messages 
requiring a response from the receiving terminal, 
said apparatus CHARACTERIZED BY 

at the first data terminal, means, respon- 
sive to the input of a signaling message requiring 
a response message, for repeatedly transmitting 
the signaling message and repeating such trans- 
mission until said response message is received 
from a second receiving terminal, 

at the second data terminal, means, re- 
sponsive to receipt of the signaling message, for 
repeatedly transmitting the response message 
u ntil a confirmation message is received from the 
first data terminal, and 

at the first data terminal, means for trans- 
mitting said confirmation message responsive to 
receipt of each response message. 

2. Apparatus to control the exchange of signaling 
messages between data terminals, individual 
ones of the signaling messages requiring a re- 
sponse from a receiving terminal and other ones 
of the signaling messages requiring a confirma- 
tion from the receiving terminal, said apparatus 
CHARACTERIZED BY 

means, operative at that one of the data 
terminals that is last to respond as a result of re- 
ceiving a signaling message from the other one 
of the data terminals, for repeating the transmis- 
sion of the response until a confirmation mes- 
sage is received from the,other one of the data 
terminals, and 

means, operative at the other one of the 
data terminals, for transmitting a confirmation 
message responsive to receipt of each said re- 
sponse message. 

3. A method of controlling the exchange of signaling 
messages between first and second data termi- 
nals, individual ones of the signaling messages 
requiring a response from the receiving terminal, 
said method CHARACTERIZED BY the steps of 

at the first data terminal, responsive to the 
input of a signaling message requiring a response 
message, transmitting the signaling message to 
said second terminal, said signaling message be- 
ing associated with a predetermined level of pri- 
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ority, and 

at said first terminal, responsive to receipt 
of a signaling message associated with said pre- 
determined level of priority from said second ter- 
minal prior to receipt of a valid response to said 5 
transmitted signaling message, entering a state 
indicative of receiving a valid response to said 
transmitted signaling message. 
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